Toward a Declarative Language for Negotiating Executable Contracts

We give an approach to automating the negotiation of business contracts. Our goal is to develop a language for both partially-specified contracts that are in the midst of being negotiated, including via automated auctions. Our starting point for this language is Courteous Logic Programs (CLP’s), a form of logic-based knowledge representation (KR) that is semantically declarative, intuitively natural, computationally tractable, and practically executable. A CLP is suitable in particular to represent a fullyspecified executable contract. The basic CLP KR also facilitates modification during negotiation, because it includes prioritized confllct handling features that facilitate modification. Beyond the basic CLP KR, we have developed an initial ontology, and an associated style of representation, to specify additional aspects of a partial contract and of a negotiation process. The initial ontology specifies the set of negotiables and the structure of a contract in terms of its component goods/services and attributes. Specifying the negotiable aspects of a good or service includes specifying tsattributes, their possible values, and dependencies/constraints on those attributes. Building upon the representation of these negotiable aspects, weare in current work developing methods to structure negotiations, especially to select and configure auction mechanisms tocarry out the negotiation. This work brings together two strands ofour previous work on business process automation in electronic commerce: representing business rules hared between terprises, and conflgurable auction mechanisms. Introduction One form of commerce that could benefit substantially from automation is contracting, where agents form binding, agreeable terms, and then execute these terms. The overall contracting process comprises several stages, including broadly: 1. Discovery. Agents find potential contracting partners. 2. Negotiation. Contract terms are determined through a communication process. 3. Ezecution. Transactions and other contract provisions are executed. In this work we are concerned primarily with negotiation, and specifically with the process by which an automated negotiation mechanism can be configured to support a particular contracting episode. Our goal is a shared language with which agents can define the scope and content of a negotiation, and reach a common understanding of the negotiation rules and the contract implications of negotiation actions. Note that we make a sharp distinction between the definition of the negotiation mechanism, and the actual negotiation strategies to be employed by participating agents. Our concern here is with the former, though of course in designing a mechanism one must consider the private evaluation and decision making performed by each of the negotiating parties. Overview of Problem and Approach The central question in configuring a contract negotiation is "What is to be negotiated?" In any contracting context, some features of the potential contract must be regarded as fixed, with others to be determined through the contracting process. At one extreme, the contract is fully specified, except for a single issue, such as price. In that case, the 39 From: AAAI Technical Report WS-99-01. Compilation copyright © 1999, AAAI (www.aaai.org). All rights reserved. negotiation can be implemented using simple auction mechanisms of the sort one sees for specified goods on the Internet. The other extreme, where nothing is fixed, is too ill-structured to consider automating to a useful degree in the current state of the art. Most contracting contexts lie somewhere in between, where an identifiable set of issues are to be determined through negotiation. Naturally, there is a tradeoff between flexibility in considering issues negotiable and complexity of the negotiation process. But regardless of how this tradeoff is resolved, we require a means to specify these issues, so that we can automatically configure the negotiation mechanisms that will resolve them. That is, we require a contracting language--a medium for expressing the contract terms resulting from a negotiation. Contracting Language In developing a shared contracting language, we are concerned with all three stages of contracting: discovery, negotiation, and execution. This multiplicity of purpose is one argument for adopting a declarative approach, with a relatively expressive knowledge representation (KR). "Declarative" here means that the semantics say which conclusions are entailed by a given set of premises, without dependence on procedural or control aspects of inference algorithms. In addition to flexibility, such an approach promotes standardization and human understandability. Traditionally, of course, contracts are specified in legally enforceable natural language ("legalese"), as in a typical mortgage agreement. This has great expressive power--but often, correspondingly great ambiguity, and is thus very difficult to automate, l, and is thus very difficult toautomate. Atthe other extreme are automated languages for restricted domains; in these, most of the meaning is implicit in the automated representation. This is the current state of Electronic Data Interchange (EDI). We are in the sparsely occupied middle ground, aiming for considerable expressive power but also considerable automatability. Our point of departure for our KR is pure logic programs (in the knowledge-representation-theory sense, not Prolog). (Baral & Gelfond (Baral & Gelfond 1994) provide a helpful review.) Logic programs are not only declarative and relatively powerful expressively, but also practical, relatively computationally efficient, and widely deployed. We embody the representation concretely as XML messages. This choice enhances human readability (via standard XML rendering/UI tools) and IEven if a natural language contract iscompletely unambiguous, it would require a vast amount of background and domain knowledge to automate. supports inclusion a d generation ftextual information. It also facilitates integration with EDI components. The XML approach further facilitates developing/maintaining parsers (via standard XML parsing tools), integrating with WWW-world software engineering, and the enriching capability o (hyper-)link to ontologies and other extra information. See (Grosof & Labrou 1999) for details about the XML representation, its advantages, and its relationship tooverall inter-agent communication. Our KR builds on our prior work representing business rules in Courteous Logic Programs (CLP’s) (Grosof 1997a)(Grosof 199Zb)(Grosof 1999a) (Grosof 1999b) (see also Section "Courteous Logic Programs as KR"). To express executable contracts, these rules must specify the goods and services tobe provided, along with applicable t rms and conditions. Such terms include customer service agreements, delivery schedules, conditions for returns, usage restrictions, and other issues relevant to the good or service provided. As part of our approach, we extend this KR with features pecific to negotiation. Foremost among these is the ability to specify partial agreements, with associated negotiable parameters. A partial agreement can be viewed as a contract emplate. Some of its parameters may be bound to particular values while others may be left open. Negotiable Parameters Once we have this contracting language, our next step will be to use it to establish t e automated negotiation process. As noted above, a key element of this is to identify the negotiable parameters. The contract template effectively defines these parameters by specifying what the contract will be for any instantiation of parameter values. The problem then, is to enable the contract language to allow descriptions of contract templates. In addition, we require auxiliary specification of possible values for parameters, and dependencies and constraints among them. Given this specification of what can be negotiated, we require a policy to determine what is actually to be included in the given negotiation episode (rather than assigned default value, or left open for subsequent resolution). This answers the question of what is to be negotiated; the remaining question is hoe#. In general, there are many ways to structure a negotiation process to resolve multiple parameters. We focus on processes mediated by auctions. Aswe describe below, the problem then becomes one of configuring appropriate auctions to manage the negotiation. Auction-Based Negotiation Mechanisms for determining price and other terms of an exchange are called auctiona. Although the